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EIP: The Extended Internet Protocol 
A Framework for Maintaining Backward Compatibility 


Status of this Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard. Distribution of this memo is 
unlimited. 


Summary 


The Extended Internet Protocol (EIP) provides a framework for solving 
the problem of address space exhaustion with a new addressing and 
routing scheme, yet maintaining maximum backward compatibility with 
current IP. EIP can substantially reduce the amount of modifications 
needed to the current Internet systems and greatly ease the 
difficulties of transition. This is an "idea" paper and discussion is 
strongly encouraged on Big-Internet@munnari.oz.au. 


Introduction 


The Internet faces two serious scaling problems: address exhaustion 
and routing explosion [1-2]. The Internet will run out of Class B 
numbers soon and the 32-bit IP address space will be exhausted 
altogether in a few years time. The total number of IP networks will 
also grow to a point where routing algorithms will not be able to 
perform routing based a flat network number. 


A number of short-term solutions have been proposed recently which 
attempt to make more efficient use of the the remaining address space 
and to ease the immediate difficulties [3-5]. However, it is 
important that a long term solution be developed and deployed before 
the 32-bit address space runs out. 


An obvious approach to this problem is to replace the current IP with 
a new internet protocol that has no backward compatibility with the 
current IP. A number of proposals have been put forward: Pip[7], 
Nimrod [8], TUBA [6] and SIP [14]. However, as IP is really the 
cornerstone of the current Internet, replacing it with a new "IP" 
reguires fundamental changes to many aspects of the Internet system 
(e.g., routing, routers, hosts, ARP, RARP, ICMP, TCP, UDP, DNS, FTP). 


Migrating to a new "IP" in effect creates a new "Internet". The 
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development and deployment of such a new "Internet" would take a very 
large amount of time and effort. In particular, in order to maintain 
interoperability between the old and new systems during the 
transition period, almost all upgraded systems have to run both the 
new and old versions in parallel and also have to determine which 
version to use depending on whether the other side is upgraded or 
not. 


Let us now have a look at the detailed changes that will be reguired 
to replace the current IP with a completely new "IP" and to maintain 
the interoperability between the new and the old systems. 


1) Border Routers: Border routers have to be upgraded and to provide 
address translation service for IP packets across the boundaries. 
Note that the translation has to be done on the outgoing IP 
packets as well as the in-coming packets to IP hosts. 


2) Subnet Routers: Subnet Routers have to be upgraded and have to 
deal with both the new and the old packet formats. 


3) Hosts: Hosts have to be upgraded and run both the new and the 
old protocols in parallel. Upgraded hosts also have to determine 
whether the other side is upgraded or not in order to choose the 
correct protocol to use. 


4) DNS: The DNS has to be modified to provide mapping for domain 
names and new addresses. 


5) ARP/RARP: ARP/RARP have to be modified, and upgraded hosts and 
routers have to deal with both the old and new ARP/RARP packets. 


6) ICMP: ICMP has to be modified, and the upgraded routers have to 
be able to generate both both old and new ICMP packets. However, 
it may be impossible for a backbone router to determine 
whether the packet comes from an upgraded host or an IP host but 
translated by the border router. 


7) TCP/UDP Checksum: The pseudo headers may have to be modified to 
use the new addresses. 


8) FTP: The DATA PORT (PORT) command has to be changed to pass new 
addresses. 


In this paper, we argue that an evolutionary approach can extend the 
addressing space yet maintain backward compatibility. The Extended 
Internet Protocol (EIP) we present here can be used as a framework by 
which a new routing and addressing scheme may solve the problem of 
address exhaustion yet maintain maximum backward compatibility to 
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current IP. 
EIP has a number of very desirable features: 


1) EIP allows the Internet to have virtually unlimited number of 
network numbers and over 10**9 hosts in each network. 


2) EIP is flexible to accommodate most routing and addressing 
schemes, such as those proposed in Nimrod [8], Pip [7], NSAP [9] 
and CityCodes [10]. EIP also allows new fields such as Handling 
Directive [7] or CI [11] to be added. 


3) EIP can substantially reduce the amount of modifications to 
current systems and greatly ease the difficulties in transition. 
In particular, it does not reguire the upgraded hosts and subnet 
routers to run two set of protocols in parallel. 


4) EIP reguires no changes to all assigned IP addresses and subnet 
structures in local are networks. and reguires no modifications 
to ARP/RARP, ICMP, TCP/UDP checksum. 


5) EIP can greatly ease the difficulties of transition. During the 
transition period, no upgrade is reguired to the subnet routers. 
EIP hosts maintain full compatibility with IP hosts within the 
same network, even after the transition period. During the 
transition period, IP hosts can communicate with any hosts in 
other networks via a simple translation service. 


In the rest of the paper, IP refers to the current Internet Protocol 
and EIP refers to the Extended Internet Protocol (EIP is pronounced 
as "ape" - a step forward in the evolution :-). 


Extended Internet Protocol (EIP) 


The EIP header format is shown in Figure 1 and the contents of the 
header follows. 
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0 Y 2 3 
0123456778901 2345678901 2345678901 
C: ————— —— — —— ——— P ——— o ++ 

| Version | IHL | Type of Service | Total Length 

dh AO A AO O O O A O A — ——— ——— -— O o — ho + 
| Identification |Flags| Fragment Offset | 
dh AO A O O O O O O A O ——— —  ——— A o o ho + 
| Time to Live | Protocol | Header Checksum 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +++ 
| Source Host Number | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +++ 
| Destination Host Number 
E: dd +++ 
| EIP ID | EIP Ext Length| EIP Extension (variable) | 
E —— ————À——— — —— o ho + 


Figure 1: EIP Header Format 
Version: 4 bits 
The Version field is identical to that of IP. This field is set 
purely for compatibility with IP hosts. It is not checked by EIP 
hosts. 
IHL: 4 bits 
Internet Header Length is identical to that of IP. IHL is set to 
the length of EIP header purely for compatibility with IP. This 
field is not checked by EIP hosts. see below the EIP Extension 
Length field for more details) 
Type of Service: 8 bits 
The ToS field is identical to that of IP. 
Total Length: 16 bits 
The Total Length field is identical to that of IP. 
Identification: 16 bits 
The Identification field is identical to that of IP. 


Flags: 3 bits 


The Flags field is identical to that of IP. 
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Fragment Offset: 13 bits 

The Fragment Offset field is identical to that of IP. 
Time to Live: 8 bits 

The Time to Live field is identical to that of IP. 
Protocol: 8 bits 

The Protocol field is identical to that of IP. 
Header Checksum: 16 bits 

The Header Checksum field is identical to that of IP. 
Source Host Number: 32 bits 

The Source Host Number field is used for identifying the 

source host but is unique only within the source network 

(the equivalent of the host portion of the source IP address). 


Destination Host Number: 32 bits 


The Destination Host Number field is used for identifying the 
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destination host but is unique only within the destination network 
(the equivalent of the host portion of the destination IP address). 


EIP ID: 8 bits 


The EIP ID field equals to 0x8A. The EIP ID value is chosen 
in such a way that, to IP hosts and IP routers, an EIP appears 


to be an IP packet with a new IP option of following parameters: 


COPY CLASS NUMBER LENGTH DESCRIPTION 


Option:  Type-TBD 
EIP Extension Length: 8 bits 
The EIP Extension Length field indicates the total length 


of the EIP ID field, EIP Extension Length field and the 
EIP Extension field in octets. The maximum length that the 


IHL field above can specify is 60 bytes, which is considered 
too short in future. EIP hosts actually use the EIP Extension 


Length field to calculate the total header length: 
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The total header length - EIP Extension Length - 20. 
The maximum header length of an EIP packet is then 276 bytes. 
EIP Extension: variable 


The EIP Extension field holds the Source Network Number, 
Destination Network Number and other fields. The format 

of the Extension field is not specified here. In its simplest 
form, it can be used to hold two fixed size fields as the 
Source Network Number and Destination Network Number as the 
extension to the addressing space. Since the Extension 

field is variable in length, it can accommodate almost any 
routing and addressing schemes. For example, the Extension 
field can be used to hold "Routing Directive" etc specified 
in Pip [7] or "Endpoint IDs" suggested in Nimrod [8], or the 
"CityCode" [10]. It can also hold other fields such as the 
"Handling Directive" [7] or "Connectionless ID" [11]. 


EIP achieves maximum backward compatibility with IP by making the 
extended space appear to be an IP option to the IP hosts and routers. 


When an IP host receives an EIP packets, the EIP Extension field is 
safely ignored as it appears to the IP hosts as an new, therefore an 
unknown, IP option. As a result, there is no need for translation 
for in-coming EIP packets destined to IP hosts and there is also no 
need for subnet routers to be upgraded during the transition period 
see later section for more details). 


EIP hosts or routers can, however, determine whether a packet is an 
IP packet or an EIP packet by examining the EIP ID field, whose 
position is fixed in the header. 


The EIP Extension field holds the Source and Destination Network 
Numbers, which are only used for communications between different 
networks. For communications within the same network, the Network 
Numbers may be omitted. When the Extension field is omitted, there is 
little difference between an IP packet and an EIP packet. Therefore, 
EIP hosts can maintain completely compatibility with IP hosts within 
one network. 


In EIP, the Network Numbers and Host Numbers are separate and the IP 
address field is used for the Host Number in EIP. There are a number 
of advantages: 


1) It maintains full compatibility between IP hosts and EIP hosts 


for communications within one network. Note that the Network 
Number is not needed for communications within one network. A 
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host can omit the Extension field if it does not need any other 
information in the Extension field, when it communicates with 
another host within the same network. 


It allows the IP subnet routers to route EIP packet by treating 
the Host Number as the IP address during the transition period, 
therefore the subnet routers are not reguired to be updated 
along the border routers. 


It allows ARP/RARP to work with both EIP and IP hosts without 
any modifications. 


It allows the translation at the border routers much easier. 
During the transition period when the IP addresses are still 
unigue, the network portion of the IP addresses can be directly 
extracted and mapped to EIP Network Numbers. 


Modifications to IP Systems 


In this section, we outline the modifications to the IP systems that 
are needed for transition to EIP. Because of the similarity between 
the EIP and IP, the amount of modifications needed to current systems 
are substantially reduced. 


1) 


Wang 


Network Numbers: Each network has to be assigned a new EIP Network 
Number based on the addressing scheme used. The mapping 

between the IP network numbers and the EIP Network Numbers can 

be used for translation service (see below). 


Host Numbers: There is no need for assigning EIP Host Numbers. 

All existing hosts can use their current IP addresses as their 
EIP Host Numbers. New machines may be allocated any number from 
the 32-bit Host Number space since the structure posed on IP 
addressing is no longer necessary. However, during the transition, 
allocation of EIP Host Numbers should still follow the IP 
addressing rule, so that the EIP Host Numbers are still globally 
unigue and can still be interpreted as IP addresses. This will 
allow a more gradual transition to EIP (see below). 


Translation Service: During the transition period when the EIP 
Host Numbers are still unigue, an address translation service 

can be provided to IP hosts that need communicate with hosts in 
other networks cross the upgraded backbone networks. The 
translation service can be provided by the border routers. When a 
border router receives an IP packet, it obtains the Destination 
Network Number by looking up in the mapping table between IP 
network numbers and EIP Network Numbers. The border router then 
adds the Extension field with the Source and Destination Network 
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Numbers into the packet, and forwards to the backbone networks. 
It is only necessary to translate the out-going IP packets to 
the EIP packets. There is no need to translate the EIP packets 
back to IP packets even when they are destined to IP hosts. 
This is because that the Extension field in the EIP packets 
appears to IP hosts just an unknown IP option and is ignored by 
the IP hosts during the processing. 


4) Border Routers: The new EIP Extension has to be implemented and 
routing has to be done based on the Network Number in the EIP 
Extension field. The border routers may have to provide the 
translation service for out-going IP packets during the transition 
period. 


5) Subnet Routers: No modifications are reguired during the transition 
period when EIP Host Numbers (which eguals to the IP 
addresses) are still globally unigue. The subnet routing is carried 
out based on the EIP Host Numbers and when the EIP Host 
IDs are still unigue, subnet routers can determine, by treating 
the EIP Host Number as the IP addresses, whether a packet is 
destined to remote networks or not and forward correctly. The 
Extension field in the EIP packets also appear to the IP subnet 
routers an unknown IP option and is ignored in the processing. 
However, subnet routers eventually have to implement the EIP 
Extension and carry out routing based on Network Numbers when 
EIP Host Numbers are no longer globally unigue. 


6) Hosts: The EIP Extension has to be implemented. routing has to 
be done based on the Network Number in the EIP Extension field, 
and also based on the Host Number and subnet mask if subnetting 
is used. IP hosts may communication with any hosts within the 
same network at any time. During the transition period when the 
EIP Host Numbers are still unique, IP hosts can communicate with 
any hosts in other network via the translation service. 


7) DNS: A new resource record (RR) type "N" has to be added for EIP 
Network Numbers. The RR type "A", currently used for IP 
addresses, can still be used for EIP Host Numbers. RR type "N" 
entries have to be added and RR type "PTR" to be updated. All 
other entries remain unchanged. 


8) ARP/RARP: No modifications are required. The ARP and RARP are 
used for mapping between EIP Host Numbers and physical 
addresses. 


9) ICMP: No modifications are required. 


10) TCP/UDP Checksum: No modifications are required. The pseudo 
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header includes the EIP Source and Destination IDs instead of 
the source and destination IP addresses. 


11) FTP: No modifications are reguired during the transition period 
when the IP hosts can still communicate with hosts in other 
networks via the translation service. After the transition period, 
however, the "DATA Port (Port)" command has to be modified to 
pass the port number only and ignore the IP address. A new FTP 
command may be created to pass both the port number and the EIP 
address to allow a third party to be involved in the file 
transfer. 


Transition to EIP 
In this section, we outline a plan for transition to EIP. 


EIP can greatly reduce the complexity of transition. In particular, 
there is no need for the updated hosts and subnet routers to run two 
protocols in parallel in order to achieve interoperability between 
old and new systems. During the transition, IP hosts can still 
communicate with any machines in the same network without any 
changes. When the EIP Host Numbers (i.e., the 32-bit IP addresses) 
are still globally unigue, IP hosts can contact hosts in other 
networks via translation service provided in the border routers. 


The transition goes as follows: 


Phase 0: 
a) Choose an addressing and routing scheme for the Internet. 
b) Implement the routing protocol. 
c) Assign new Network Numbers to existing networks. 
Phase l: 
a) Update all backbone routers and border routers. 
b) Update DNS servers. 
c) Start translation service. 
Phase 2: 


a) Update first the key hosts such as mail servers, DNS servers, 
FTP servers and central machines. 
b) Update gradually the rest of the hosts. 


Phase 3: 
a) Update subnet routers 


b) Withdraw the translation service. 


The translation service can be provided as long as the Host IDs 
(i.e., the 32-bit IP address) are still globally unigue. When the IP 
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address space is exhausted, the translation service will be withdrawn 
and the remaining IP hosts can only communicate with hosts within the 
the same network. At the same time, networks can use any numbers in 
the 32-bit space for addressing their hosts. 


Related Work 


A recent proposal called IPAE by Hinden and Crocker also attempts to 
minimize the modifications to the current IP system yet to extend the 
addressing space [12]. IPAE uses encapsulation so that the extended 
space is carried as IP data. However, it has been found that the 64 
bits IP data returned by an ICMP packet is too small to hold the 
Global IP addresses. Thus, when a router receives an ICMP generated 
by an old IP host, it is not able to convert it into a proper ICMP 
packet. More details can be found in [13]. 


Discussions 


EIP does not necessary increase the header length significantly as 
most of the fields in the current IP will be still needed in the new 
internet protocol. There are debates as to whether fragmentation and 
header checksum are necessary in the new internet protocol but no 
consensus has been reached. 


EIP assumes that IP hosts and routers ignore unknown IP option 
silently as reguired by [15,16]. Some people have expressed some 
concerns as to whether current IP routers and hosts in the Internet 
can deal with unknown IP options properly. 


In order to look into the issues further, we carried out a number of 
experiments over the use of IP option. We selected 35 hosts over 30 
countries across the Internet. A TCP test program (based on ttcp.c) 
then transmitted data to the echo port (tcp port 7) of each of the 
hosts. Two tests were carried out for each host, one with an unknown 
option (type 0x8A, length 40 bytes) and the other without any 
options. 


It is difficult to ensure that the conditions under which the two 
tests run are identical but we tried to make them as close as 
possible. The two tests (test-opt and test-noopt) run on the same 
machine a Sun4) in parallel, i.e., "test-opt& ; test-noopt&" and then 
again in the reverse order, i.e., "test-noopt& ; test-opt&", so each 
test pair actually run twice. Each host was ping'ed before the tests 
so that the domain name information was cached before the name 
lookup. 


The experiments were carried out at three sites: UCL, Bellcore and 
Cambridge University. The tcp echo throughput (KB/Sec) results are 
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listed in Appendix. 


The results show that the IP option was dealt with properly and there 
is no visible performance difference under the test setup. 
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Appendix 


Throughput Test from UCL (sartre.cs.ucl.ac.uk) 


Destination Host test-noopt test-opt 

oliver.cs.mcgill.ca 1.128756 1.285345 
oliver.cs.mcgill.ca 1.063096 1.239709 
bertha.cc.und.ac.za 0.094336 0.043917 
bertha.cc.und.ac.za 0.075681 0.057120 
vnet3.vub.ac.be 2.090622 2.228181 
vnet3.vub.ac.be 1.781374 1.692740 
itdsrvl.ul.ie 15.937596 2.062579 
itdsrvl.ul.ie 1.928313 1.936784 
sunic.sunet.se 11.064797 11.724055 
sunic.sunet.se 10.861720 10.840306 
pascal.acm.org 2.463790 0.810133 
pascal.acm.org 1.619088 0.860198 
iti.gov.sg 1.565320 1.983795 
iti.gov.sg 1.564788 1.921803 
rzusuntk.unizh.ch 9.903805 11.335920 
rzusuntk.unizh.ch 9.597806 10.678098 
funet.fi 9.897876 9.382925 
funet.fi 10.487118 11.023745 
odin.diku.dk 5.851407 5.482946 
odin.diku.dk 5.992257 6.243283 
cphkvx.cphk.hk 0.758044 0.844406 
cphkvx.cphk.hk 0.784532 0.745606 
bootes.cus.cam.ac.uk 28.341705 29.655824 
bootes.cus.cam.ac.uk 24.804125 23.240990 
pesach.jct.ac.il 1.045922 1.115802 
pesach.jct.ac.il 1.330429 0.978184 
sunl.sara.nl 10.546733 11.500778 
sunl.sara.nl 9.624833 10.214136 
cocos.fuw.edu.pl 1.747777 1.702324 
cocos.fuw.edu.pl 1.676151 1.716435 
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apple.com 4.449559 4.145081 
apple.com 6.431675 5.520443 
gorgon.tf.tele.no 1.199810 1.374546 
gorgon.tf.tele.no 0.508642 0.993261 
kogwy.cc.keio.ac.jp 3.626448 3.249590 
kogwy.cc.keio.ac.jp 3.913777 4.094849 
exu.inf.puc-rio.br 1.913925 1.795235 
exu.inf.puc-rio.br 1.154936 1.114775 
inria.inria.fr 2.299561 0.599665 
inria.inria.fr 1.219282 0.873672 
kum.kaist.ac.kr 0.252704 0.254199 
kum.kaist.ac.kr 0.236196 0.172367 
sunipcl.labein.es 1.398777 1.243588 
sunipcl.labein.es 0.876177 0.602964 
wifosv.wsr.ac.at 0.531153 0.803387 
wifosv.wsr.ac.at 0.773935 0.557798 
uunet.uu.net 7.813556 6.764543 
uunet.uu.net 7.969203 6.657325 
infnsun.aguila.infn.it 2321197 2.402477 
infnsun.aguila.infn.it 2.400196 2.695016 
muttley.fc.ul.pt 0.545775 0.434672 
muttley.fc.ul.pt 0.284124 0.266017 
dmssyd.syd.dms.csiro.au 2.734685 2.857545 
dmssyd.syd.dms.csiro.au 1.168154 1.462789 
hamlet.caltech.edu 2.552804 2.897286 
hamlet.caltech.edu 3.839141 2.407945 
sztaki.hu 0.294196 0.403697 
sztaki.hu 0.236260 0.388755 
menvax.restena.lu 0.465066 0.515361 
menvax.restena.lu 0.358646 0.511985 
nctu.edu.tw 0.484372 0.816722 
nctu.edu.tw 0.705733 1.109228 
xalapa.lania.mx 0.899529 0.822544 
xalapa.lania.mx 1.150058 0.881713 
truth.waikato.ac.nz 1.438481 1.993749 
truth.waikato.ac.nz 1.325041 1.833999 
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Throughput Test from Bellcore 


Destination Host 


oliver.cs. 
oliver.cs. 
bertha.cc. 
bertha.cc. 
vnet3.vub. 
vnet3.vub. 
itdsrvl.ul.ie 
itdsrvl.ul.ie 
sunic.sunet.se 
sunic.sunet.se 
pascal.acm.org 
pascal.acm.org 
iti.gov.sg 
iti.gov.sg 


rzusuntk.unizh. 
rzusuntk.unizh. 


funet.fi 
funet.fi 
odin.diku.dk 
odin.diku.dk 
cphkvx.cphk.hk 
cphkvx.cphk.hk 
bootes 
bootes 
pesach. 
pesach. 
sunl.sara.nl 
sunl.sara.nl 


cocos.fuw.edu.pl 
cocos.fuw.edu.pl 


apple.com 
apple.com 


gorgon.tf.tele.no 
gorgon.tf.tele.no 
kogwy.cc.keio.ac.jp 
kogwy.cc.keio.ac.jp 
exu.inf.puc-rio.br 
exu.inf.puc-rio.br 


inria.inria.fr 
inria.inria.fr 


kum.kaist.ac.kr 
kum.kaist.ac.kr 
sunipcl.labein.es 
sunipcl.labein.es 


.cus.cam. 
.cus.cam. 
Jetsac.dil 
jct.ac.il 


EIP 


ch 
ch 


ac.uk 
ac.uk 


HA 
DFPOOFVDONNWHAOFWNDOWWOOWNDOUNITANABANNENNNDAOCDCCCOHFFE 


test- 
.820014 
.979981 
.099289 
.118627 
.368476 
.443269 
.721444 
113952 
.989907 
.100563 
.487185 
. 944085 
.401733 
. 950990 
. 094820 
.952650 
. 703408 
.389722 
.094152 
.362362 
.092698 
. 496394 
632951 
.717170 
. 684029 
.390263 
. 186035 
.053797 
.154405 
.120283 
.588979 
.861733 
.280217 
.243205 
.249789 
.387490 
.089536 
.476758 
.653974 
.739127 
.541682 
.906632 
.101496 
.054245 


noopt 


test-opt 


.128104 
. 866815 
. 035877 
103763 
. 694463 
. 644050 
. 960068 
.953275 
.956766 
.010292 
.896253 
.269323 
.735445 
.793121 
.618023 
.245001 
.928008 
.815122 
.450695 
.690722 
.106880 
.681994 
.631322 
.335914 
.921621 
.095265 
.325166 
.081236 
.124795 
.105825 
.957880 
.211125 
.112675 
.631096 
.075968 
.583511 
¿233111 
.249439 
.866246 
.130521 
.312546 
.042793 
.091456 
.101585 


hu 
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wifosv.wsr.ac.at 
wifosv.wsr.ac.at 
uunet.uu.net 
uunet.uu.net 
infnsun.aguila.infn.it 
infnsun.aguila.infn.it 
muttley.fc.ul.pt 
muttley.fc.ul.pt 
dmssyd.syd.dms.csiro.au 
dmssyd.syd.dms.csiro.au 
hamlet.caltech.edu 
hamlet.caltech.edu 
sztaki.hu 

sztaki.hu 
menvax.restena.lu 
menvax.restena.lu 
nctu.edu.tw 
nctu.edu.tw 
xalapa.lania.mx 
xalapa.lania.mx 
truth.waikato.ac.nz 
truth.waikato.ac.nz 


EIP 


MwMwoooeooooommnoooooo——oooo 


.044443 
.596935 
.530348 
.941888 
.619418 
.156780 
.353632 
.221522 
.433901 
.408975 
.367756 
.828718 
.301120 
.253222 
.364221 
.456882 
.246523 
.423476 
.748642 
.716781 
.197595 
.489748 


NONOOOoH|oOoOoOoocUOU0to0oonmnn0000 


.369528 
.870377 
. 999789 
.075660 
.569645 
.158000 
.416126 
.155505 
.272839 
.130188 
.325031 
.676571 
.362481 
.519892 
.480789 
.580778 
.199412 
.630833 
.607284 
.643030 
.072601 
.186684 
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Destination Hos 


E 


oliver.cs.mcgil 
oliver.cs.mcgil 
bertha.cc.und.a 
bertha.cc.und.a 
vnet3.vub.ac.be 
vnet3.vub.ac.be 
itdsrvl.ul.ie 
itdsrvl.ul.ie 
sunic.sunet.se 
sunic.sunet.se 
pascal.acm.org 
pascal.acm.org 
iti.gov.sg 
iti.gov.sg 
rzusuntk.unizh. 
rzusuntk.unizh. 
funet.fi 
funet.fi 
odin.diku.dk 
odin.diku.dk 
cphkvx.cphk.hk 
cphkvx.cphk.hk 


bootes.cus.cam.ac.uk 
bootes.cus.cam.ac.uk 


pesach.jct.ac.i 
pesach.jct.ac.i 
sunl.sara.nl 
sunl.sara.nl 
cocos.fuw.edu.p 
cocos.fuw.edu.p 
apple.com 
apple.com 
gorgon.tf.tele. 
gorgon.tf.tele. 


ch 
ch 


l 
l 


d 
l 


no 
no 


kogwy.cc.keio.ac.jp 
kogwy.cc.keio.ac.jp 
exu.inf.puc-rio.br 
exu.inf.puc-rio.br 


inria.inria.fr 
inria.inria.fr 
kum.kaist.ac.kr 
kum.kaist.ac.kr 
sunipcl.labein. 
sunipcl.labein. 


es 
es 


test-noopt 


.128756 
.063096 
.031218 
.034405 
.568487 
.558238 
.064302 
.852089 
.179942 
.772485 
.661248 
.557839 
.600616 
.772887 
.645913 
.853503 
.190147 
.270988 
.361227 
971774 
.173451 
.151376 
.589141 
.203020 
.343598 
.582809 
.529277 
.896041 
.131180 
.137697 
.330794 
.856476 
.094793 
.167257 
.154681 
.095814 
.454272 
.705198 
.149511 
.071125 
.721184 
.250285 
.519284 
.990174 
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00000000 rO0000roooro 


(cus.cam.ac.uk) 


test-opt 


.285345 
.239709 
.031221 
.034925 
.731320 
.581415 
.284707 
.025779 
.270326 
. 689160 
.726125 
.428193 
. 926690 
.956636 
.504969 
.671272 
.421110 
.789678 
.993901 
.415716 
.298421 
.184210 
.920081 
.556436 
.492202 
.930958 
.470571 
.894923 
.142239 
.148895 
.453590 
.714661 
.099981 
.151625 
.178868 
.871496 
.384484 
.690708 
.150021 
.077257 
.549511 
.296195 
.491745 
.009475 


r2pb.KHuooco.&lgs0ocorm|mP|oormnmemnmooocoonmprHa 


NN 
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wifosv.wsr.ac.at 
wifosv.wsr.ac.at 
uunet.uu.net 
uunet.uu.net 
infnsun.aguila.infn.it 
infnsun.aguila.infn.it 
muttley.fc.ul.pt 
muttley.fc.ul.pt 
dmssyd.syd.dms.csiro.au 
dmssyd.syd.dms.csiro.au 
hamlet.caltech.edu 
hamlet.caltech.edu 
sztaki.hu 

sztaki.hu 
menvax.restena.lu 
menvax.restena.lu 
nctu.edu.tw 
nctu.edu.tw 
xalapa.lania.mx 
xalapa.lania.mx 
truth.waikato.ac.nz 
truth.waikato.ac.nz 


Security Considerations 


Security issues are not discussed in this memo. 
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Wang 


EIP 


E—E—ooeoMooooooo—oooooomnsoo 


.360751 
.344268 
.247430 
.139251 
.480731 
.230471 
.239624 
.586156 
.630623 
.743162 
.897946 
.118200 
.338358 
«113328 
.224967 
.452945 
.549709 
.229093 
.713586 
.612278 
.438481 
.325041 


FPROONNDTIDOOOUBNWODDONWOO 


.418554 
.326605 
.305592 
. 945469 
.782631 
.292273 
.334286 
.419485 
. 607504 
.994665 
. 650703 
.622022 
.225206 
.112637 
.359237 
.472345 
.037245 
.469851 
.810107 
.731705 
.993749 
. 833999 
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